昨天提到的 AI 很容易因為接收到的 Context 而影響輸出的水準，那軟體工程又能透過什麼方式解決此問題呢？

想像一種情境，小時候疊積木蓋房子時，在底座歪斜不穩的情況下，是很難持續往上疊的。相反的，如果底座穩定並且堅固，則較容易繼續打造出完美且成熟的物件。

開發時也是如此。隨著需求的變動，我們得重新檢查原本的假設與程式結構是否還適用。若在不清理的情況下持續開發，就很容易提高開發所需要的精力成本。

那昨天留下的問題就來了：軟體工程如何幫助我們與 AI 一起面對這些變動？

Recap 一下軟體工程的特性

軟體工程兩大重點：

1. 軟體工程是一套 系統／方法，他幫助我們更順利地進行開發與維護。
2. 軟體開發通常不存在一套永遠適用的「最優解」。

當問題規模很小、需求固定，而且幾乎沒有後續維護成本時，很多軟體工程方法的價值確實不容易體現。

但如果開發的是一個會持續變動與更新的軟體，我們就得考慮：下次需求進來時，是否知道該從哪裡著手，這些變動是否影響其他方，又是否會造成錯誤。

軟體工程的各種方法，就是在處理這些問題。至於需要做到什麼程度，仍然得看專案的情境，沒有一套永遠適用的最優解。

這跟 AI 有什麼關係？

回到昨天的 Context。
AI 在修改程式時，需要知道目前的設計理由、既有的程式行為，以及這次修改要達成什麼目標。

如果這些資訊只存在我們腦中，或者散落在前後矛盾的對話裡，AI 就可能根據不完整或錯誤的資訊繼續往下做。
而若有良好的風格與架構設計，則可在不特別提醒 ai 的情況下，遵照目前的框架下去實作，進而保持良好的品質與降低出錯的可能性。

例如，程式中準確的命名能表達其用途；責任劃分清楚的架構能降低修改時的範圍；文件可以記錄需求與設計理由；測試則能把部分預期行為變成可執行的檢查。藉此，當 AI 在讀取這些內容時，就降低了額外判斷與猜測的行為，進而提高任務交付的水準。
另一方面，如果程式各部分的責任能清楚劃分，降低模糊地帶，人與AI 也都能較容易提供準確的指示與敘述而不需要解釋半天。這不僅在對 AI、對人、對同事上都是更好的影響。

當然，前提是這些內容仍然反映現況。需求改了，文件與測試卻沒更新，反而可能成為另一個誤導來源。所以重點也包括：修改功能時，一起確認哪些既有資訊與決定需要調整。
而整理文件、探索不同拆法、補上測試與執行檢查，這些過往人類最不想做的瑣事，AI 能協助完成。這也是我覺得兩者能相輔相成的地方：工程方法讓合作有依據，AI 則有機會降低實踐這些方法的成本。

那我們為什麼還需要自己了解？

你可能會覺得，現在 AI 能力那麼強，在 prompt 裡提醒它「保持乾淨的架構、遵守軟體工程原則」，不就好了？

首先 Know how 絕對是人類最基本的必備條件，有足夠知識你才能更有效率地使用 AI agent 並且與其討論。

一直很喜歡李宏毅老師提過的一個例子，人類之於AI，就像是坐在大象上的象伏，大象是有能力的，但若無法好好下指令駕馭 也無法得到你想要的結果。
而且如同recap提到的重點，軟體開發不存在最佳解。在各個設計架構之間是存在不同 tradeoff 的。

所以相比於只要求「請保持良好的架構」，若有相關的背景知識，能更容易的與其進行討論並且釐清實際需求
並且在與AI對話時產生的摩擦，不僅讓能加深對於作品的理解，也提高對其能力的掌握度。 可喜可賀。

但，AI又已經這麼發達了，這過程中，部分老舊的軟工概念有機會淡出，也有新的維度需要帶入。
這也是我想透過這個系列挑戰的事情：並且如何系統化的介紹AI時代下的軟體工程。

接下來的 roadmap

接下來，這個系列會沿著三個階段展開：從檢查 AI 交付的程式，到參與程式的設計，再到判斷一個設計是否值得繼續使用。每個主題都會搭配例子，討論實際開發時可以怎麼與 AI 合作。

1. 建立規則，讓每次修改有依據

AI 交出一批程式碼之後，我們需要知道它改了什麼、是否符合需求，以及出了問題要怎麼回復。這些是接手程式最基本的需要，也適合當作起點。

這一階段會從命名、function 長度與參數量談起，減少讀懂程式所需的力氣；再透過 formatter、linter、Git 與測試，建立固定的檢查方式。設計文件與決策紀錄則用來保存程式碼沒有交代的理由，讓下一次修改有跡可循。其中有些只需要設定工具，有些可以請 AI 協助整理，容易從既有專案開始實踐。

2. 拆解需求，決定程式如何分工

當我們請 AI「做一個結帳功能」，其實也把許多設計決定交給了它：計價放在哪裡、誰負責更新庫存、付款與訂單如何配合。想參與這些決定，就需要理解一個需求如何變成程式結構。

這一階段會練習把流程拆成各自有明確責任的部分，安排資料與行為，再比較程序導向與物件導向如何表達同一個需求。function、class、組合與繼承，都會放回具體例子裡討論。學到這裡，應該能向 AI 說明預期的分工，也能看出它的實作是否符合這個安排。

3. 面對變動，判斷設計的代價

設計的好壞，往往要等需求改變才看得清楚。新增一種折扣時，可能只需要調整計價，也可能得一路改到訂單與付款。追查這些修改為什麼連在一起，就能開始理解模組之間的依賴，以及原本的責任劃分出了什麼問題。

最後會以這類情境介紹抽象與實作、SOLID 等設計原則，並視需要搭配 design pattern 或資料庫的案例。比較方案時，除了看它讓哪些修改變容易，也要算進新增介面、理解流程與維護程式的成本。這能幫助我們在 AI 提出設計建議時，具體討論它解決了什麼問題，以及目前是否需要付出這筆成本。

明天先從閱讀程式開始：AI 寫出來的 code，要花多少力氣才能看懂？